71

What are the differences between NoSQL and a traditional RDBMS?

Over the last few months, NoSQL has been frequently mentioned in the technical news. What are its most significant features relative to a traditional RDBMS? At what level (physical, logical) do the differences occur?

Where are the best places to use NoSQL? Why?

Improve this question
0

6 Answers 6

Reset to default
62

NoSQL stands for "Not only SQL" and usually means that the database is not a relational database, which have been very popular the last decades.

The reason why NoSQL has been so popular the last few years is mainly because, when a relational database grows out of one server, it is no longer that easy to use. In other words, they don't scale out very well in a distributed system. All of the big sites that you mentioned Google, Yahoo, Facebook and Amazon (I don't know much about Digg) have lots of data and store the data in distributed systems for several reasons. It could be that the data doesn't fit on one server, or there are requirements for high availability.

CAP Theorem

The properties of a distributed system can be described by the CAP Theorem. Of the three properties you can only have at most two:

  • C​onsistency
  • A​vailability
  • tolerance to network P​artitioning

Amazon Dynamo uses Eventual Consistency to come close to get all three properties. The paper Dynamo: Amazon’s Highly Available Key-value Store is worth reading when learning about NoSQL databases and distributed systems. Amazon Dynamo has the A and P properties.

Google take a different approach with BigTable, that has the C and A properties.

Other NoSQL databases

As I wrote in the beginning there are many other kind of NoSQL databases, that are designed for different requirements. E.g. graph databases like Neo4j, document databases like CouchDB and multimodel / object databases like OrientDB.

Finally I would like to say that relational databases will remain popular. They are very flexible and maintainable. But they are not always the best choice.

Improve this answer
4
  • 2
    Good, exhaustive answer.
    – TML
    Commented Jan 5, 2011 at 6:32
  • NoSQL does NOT mean non-relational, it just means something other than a SQL DBMS.
    – nvogel
    Commented Mar 31, 2011 at 12:04
  • 1
    It seems that at the recent O'Reilly Strata Conference, Mark Madsen has coined a new interpretation of "NoSQL" in his history of databases in no-tation to supersede "Not Only SQL". It is now: "No, SQL" ;-)
    – Lukas Eder
    Commented Dec 14, 2013 at 20:01
  • 6
    "Not only" was a retrofit, the early NoSQL movement was rabidly against relational databases. Then they hit the real world.
    – Gaius
    Commented May 7, 2014 at 8:27
22

NoSQL is a very broad term and typically is referred to as meaning "Not Only SQL." The term is dropping out of favor in the non-RDBMS community.

You'll find that NoSQL database have few common characteristics. They can be roughly divided into a few categories:

  • key/value stores
  • Bigtable inspired databases (based on the Google Bigtable paper)
  • Dynamo inspired databases
  • distributed databases
  • document databases

This is a huge question, but it's fairly well answered in this Survey of Distributed Databases.

For a short answer:

NoSQL databases may dispense with various portions of ACID in order to achieve certain other benefits--partition tolerance, performance, to distribute load, or to scale linearly with the addition of new hardware.

As far as when to use them--that depends entirely on the needs of your application.

Improve this answer
12

NoSQL is a kind of database that doesn't have a fixed schema like a traditional RDBMS does. With the NoSQL databases the schema is defined by the developer at run time. They don't write normal SQL statements against the database, but instead use an API to get the data that they need. The NoSQL databases can usually scale across different physical servers easily without needing to know which server the data you are looking for is on.

However there are some trade offs for all this flexibility: The NoSQL databases are pretty feature lacking compared to the RDBMS systems like SQL Server, Oracle, DB2, MySQL, etc. There's no Service Broker, Transaction logging, ETL packages, etc.

NoSQL isn't something that is new. It has actually been around for 50-60 years. Back then it was called COBOL. Same exact idea, just a different group came up with it.

Improve this answer
8
  • 3
    Point 1 is incorrect for many (all?) NoSQL databases unless you've explicitly told the database that you don't care if writes succeed. E.g. Any Hadoop backed database will write the data to three locations come hell or high water. By default, Cassandra will write to three locations and acknowledge the write as successful when two have succeeded.
    – anon
    Commented Jan 3, 2011 at 21:16
  • 3
    How does it handle concurrency when doing those updates? Is there a distributed type transaction that goes between them, or is the write ACKed before hand and the servers handle the rest in the background?
    – mrdenny
    Commented Jan 3, 2011 at 21:48
  • Concurrency depends entirely on implementation. Riak uses vector clocks to ensure concurrency and in the event of conflicting writes they can be returned to the calling application for resolution. Others use a last write wins.
    – anon
    Commented Jan 3, 2011 at 22:09
  • As far as write acknowledgement - in most cases, writes aren't acknowledged until the OS acknowledges the write. You can even go so far as to request acknowledgement of durable writes which means that the bits are actually flushed to disk instead of being in OS buffer. MongoDB acknowledges writes to memory by default but can be configured to require acknowledgement of write to disk. The replication is handled differently with every product. With Hadoop, client writes to server A which writes to B which writes to C. Once C responds the write is complete and the client gets a write ack.
    – anon
    Commented Jan 3, 2011 at 22:14
  • In that case I stand corrected. I've removed the incorrect statement. Did I FUBAR anything else?
    – mrdenny
    Commented Jan 5, 2011 at 1:11
6

Basically dispensing with the relational setup, with primary and foreign keys, and with the additional overhead involved in keeping transactional safety, often gives you extreme increases in performance. However this is not unique to the new databases/datastores, as eg MySQL has been tuned to perform at "NoSQL levels" by bypassing layers.

In short, you can often get impressive performance if you're ok with taking the risk of possibly losing data. Most NoSQL systems do this. Eg MongoDB stages data changes to be written when it's convenient. The data itself is safe and transactionally secure, but kept in volatile storage (memory). If you lose power you can't be 100% sure that you haven't lost data, or that you don't have corrupted data.

It's a trade off between security and performance.

Improve this answer
5

A good place to start is the Wikipedia entry. Essentially instead relating data in one table to another you store things as key value pairs and there is no database schema, it is handled instead in code.

A few sites use both NoSQL and the typical RDBMS servers concurrently, but to store different data. So you don't have to choose one or the other.

Improve this answer
2
  • The fact that the bulk of this question can be answered by going to WP makes me rub my chin as I contemplate the answers here. I think it's a little too "filler question" but that's really all we have right now.
    – jcolebrand ♦
    Commented Jan 5, 2011 at 4:58
  • 1
    The important note here is that eschewing relations (foreign key) support in the database/server infrastructure relieves the database/servers from the load and lock-management overhead of maintaining referential integrity. The consequence of this, the trade-off, is that referential integrity, consistency, and the other ACID concerns are then pushed out to the applications. Many applications benefit from this rather than being limited by it. (Some applications have to be wedged into the client/server model).
    – Jim Dennis
    Commented Mar 31, 2011 at 22:51
1

I have heavily worked on the MongoDB NoSQL Database and Oracle.

Schema

SQL database has its own predefined schema to store structured data.

In NoSQL database, there is no predefined schema, here schema is most dynamic element based on the data elements.

Scalability

SQL Databases are vertically scalable, which means if we want to scale SQL base database, we need to give hardware boost on which the DBMS System is installed. This is where it sometimes goes for the limitation of scalability.

NoSQL databases are horizontally scalable, means if we want to scale it, we need to add more nodes and create distribution network based on our own need and required power. This is how they reduce load on the database

Data Retrieval

In SQL based databases, to define and manipulate data we can use SQL (Structured Query Language), which is very powerful nowadays.

In terms of NoSQL database, queries focus on collection and documents. Sometimes it is called UnQL (Unstructured Query Language). This is still in the evolution phase, so it varies from vendor to vendor of the NoSQL database.

For more on key differences, my blog: Difference between SQL and NoSQL database

Improve this answer
1
  • Should be noted, some NoSQL databases also support predefined schema, e.g. MongoDB: Schema Validation. Of course, this is not a real "schema", the focus is more on "validation of data".
    – Wernfried Domscheit
    Commented Oct 21, 2022 at 8:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.